updating initial workflows to create tags#23
Open
sean-sype-simmons wants to merge 4 commits intomainfrom
Open
Conversation
There was a problem hiding this comment.
Pull request overview
Adds end-user documentation and a reusable workflow to support semantic version tagging/releases for the chef/common-github-actions reusable workflow suite, along with updated stub guidance for pinning workflows by tag.
Changes:
- Added a reusable
create-release-tag.ymlworkflow to calculate, create, and push a semantic version tag (and create a GitHub Release). - Added new documentation pages (
HOW-TO-USE.md,PIPELINE-REFERENCE.md) and linked them prominently fromREADME.md. - Simplified the CI stub workflow by removing stub-version echoing and adding guidance to pin to tags.
Reviewed changes
Copilot reviewed 6 out of 6 changed files in this pull request and generated 1 comment.
Show a summary per file
| File | Description |
|---|---|
| README.md | Adds prominent links to the new usage/reference documentation. |
| HOW-TO-USE.md | New quick-start and configuration guide, including tag-based versioning guidance. |
| PIPELINE-REFERENCE.md | New comprehensive reference for pipeline jobs/tools and their mappings. |
| .github/workflows/stubs/create-release-tag-stub.yml | New stub workflow for consumers to call the tag/release workflow. |
| .github/workflows/stubs/ci-main-pull-request-stub.yml | Removes stub-version echo job; adds guidance to pin reusable workflow by tag. |
| .github/workflows/create-release-tag.yml | New reusable workflow implementing tag calculation, tag push, and GitHub Release creation. |
Comments suppressed due to low confidence (4)
HOW-TO-USE.md:75
- The copy commands reference files without the
workflow-supporting-files/sonar-templates/prefix, so they won’t work when run from a consumer repo. Update the examples to include the correct relative path (or clarify that the templates must be copied out of this repository first).
Copy the appropriate template from `workflow-supporting-files/sonar-templates/` to your repository root:
```bash
# For Go projects
cp GO-sonar-project.properties sonar-project.properties
# For Ruby projects
cp RUBY-sonar-project.properties sonar-project.properties
# For Rust projects
cp RUST-sonar-project.properties sonar-project.properties
**.github/workflows/create-release-tag.yml:120**
* If `version_bump` is anything other than major/minor/patch, the `case` falls through and silently keeps the same version. It would be safer to add a default case that fails the workflow with an error so an invalid input can’t produce an unexpected tag.
# Calculate new version based on bump type
case $BUMP_TYPE in
major)
MAJOR=$((MAJOR + 1))
MINOR=0
PATCH=0
;;
minor)
MINOR=$((MINOR + 1))
PATCH=0
;;
patch)
PATCH=$((PATCH + 1))
;;
esac
**.github/workflows/create-release-tag.yml:177**
* The summary always reports `v${{ steps.calc_version.outputs.new_version }}` as the "New Tag" even when tag creation is skipped because it already exists. Use the actual created tag output (or explicitly indicate the tag was skipped) to avoid misleading workflow summaries.
- name: Output summary
run: |
echo "## 🏷️ Release Tag Summary" >> $GITHUB_STEP_SUMMARY
echo "" >> $GITHUB_STEP_SUMMARY
echo "| Property | Value |" >> $GITHUB_STEP_SUMMARY
echo "|----------|-------|" >> $GITHUB_STEP_SUMMARY
echo "| Previous Tag | ${{ steps.get_latest_tag.outputs.latest_tag }} |" >> $GITHUB_STEP_SUMMARY
echo "| New Tag | v${{ steps.calc_version.outputs.new_version }} |" >> $GITHUB_STEP_SUMMARY
echo "| Commit SHA | ${{ github.sha }} |" >> $GITHUB_STEP_SUMMARY
**.github/workflows/create-release-tag.yml:247**
* `softprops/action-gh-release` is configured with both `body_path` and `generate_release_notes: true`. These options can conflict (GitHub-generated notes may override or duplicate the provided body). Prefer one approach: either rely on generated release notes, or keep `body_path` and set `generate_release_notes` to false.
- name: Create GitHub Release
uses: softprops/action-gh-release@v2
with:
tag_name: ${{ needs.create-tag.outputs.new_tag }}
name: "Release ${{ needs.create-tag.outputs.new_tag }}"
body_path: release_notes.md
draft: false
prerelease: false
generate_release_notes: true
</details>
---
💡 <a href="/chef/common-github-actions/new/main/.github/instructions?filename=*.instructions.md" class="Link--inTextBlock" target="_blank" rel="noopener noreferrer">Add Copilot custom instructions</a> for smarter, more guided reviews. <a href="https://docs.github.com/en/copilot/customizing-copilot/adding-repository-custom-instructions-for-github-copilot" class="Link--inTextBlock" target="_blank" rel="noopener noreferrer">Learn how to get started</a>.
Contributor
Author
|
Will need to create a manual tag prior to this being merged. |
There was a problem hiding this comment.
Pull request overview
Copilot reviewed 6 out of 6 changed files in this pull request and generated 1 comment.
Comments suppressed due to low confidence (3)
HOW-TO-USE.md:74
- The copy commands for
sonar-project.propertiesomit theworkflow-supporting-files/sonar-templates/path mentioned just above, so they won’t work as written. Update the examples to include the full relative path (or clarify where the templates should be downloaded from) so users can copy the correct files.
Copy the appropriate template from `workflow-supporting-files/sonar-templates/` to your repository root:
```bash
# For Go projects
cp GO-sonar-project.properties sonar-project.properties
# For Ruby projects
cp RUBY-sonar-project.properties sonar-project.properties
# For Rust projects
cp RUST-sonar-project.properties sonar-project.properties
.github/workflows/create-release-tag.yml:266
git log ${PREVIOUS_TAG}..HEADcan include commits beyond the tag being released (depending on whatHEADpoints to after checkout). Generate the changelog against the specific tag/sha you’re releasing (for example${PREVIOUS_TAG}..${NEW_TAG}) so the release notes are deterministic.
# Generate changelog between tags
if [ "$PREVIOUS_TAG" != "v0.0.0" ]; then
CHANGELOG=$(git log --pretty=format:"- %s (%h)" ${PREVIOUS_TAG}..HEAD 2>/dev/null || echo "- Initial release")
else
PIPELINE-REFERENCE.md:260
polaris-detect-search-depthis documented here as defaulting to'5', but the actual reusable workflow input currently defaults to an empty string (and is then passed asnullwhen unset). Please update the documentation to match the real default behavior, or change the workflow default if'5'is intended.
- `polaris-coverity-args` (string) - Additional Coverity arguments
- `polaris-detect-search-depth` (string) - Detect search depth, default: '5'
- `polaris-detect-args` (string) - Additional Detect arguments
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
updated documentation removed some options for stub versions Signed-off-by: Sean Simmons <ssimmons@progress.com>
Signed-off-by: Sean Simmons <ssimmons@progress.com>
Signed-off-by: Sean Simmons <ssimmons@progress.com>
Signed-off-by: Sean Simmons <ssimmons@progress.com>
sean-sype-simmons
force-pushed
the
sean-sype-simmons/AddVersioningforWorkflows
branch
from
4bc7472 to
58f5288
Compare
There was a problem hiding this comment.
Pull request overview
Copilot reviewed 6 out of 6 changed files in this pull request and generated no new comments.
Comments suppressed due to low confidence (4)
HOW-TO-USE.md:371
- The date "2024" appears to be incomplete or placeholder. It should include a specific month and day, or at minimum a month (e.g., "Dec 2024" or "2024-12-15") to provide meaningful version history information.
| v1.0.5 | 2024 | Initial release with core security scanning |
.github/workflows/create-release-tag.yml:243
- The output "new_tag" is only set when a tag is successfully created (line 217), but the "Output summary" step (lines 225-243) always runs and tries to reference this output. If tag creation is skipped because the tag already exists, the "new_tag" output will be empty, but the summary will still try to display it. Consider adding a condition to the Output summary step to handle both scenarios appropriately, or ensure the output is always set (even when skipped).
- name: Output summary
run: |
echo "## 🏷️ Release Tag Summary" >> $GITHUB_STEP_SUMMARY
echo "" >> $GITHUB_STEP_SUMMARY
echo "| Property | Value |" >> $GITHUB_STEP_SUMMARY
echo "|----------|-------|" >> $GITHUB_STEP_SUMMARY
echo "| Previous Tag | ${{ steps.get_latest_tag.outputs.latest_tag }} |" >> $GITHUB_STEP_SUMMARY
echo "| New Tag | v${{ steps.calc_version.outputs.new_version }} |" >> $GITHUB_STEP_SUMMARY
echo "| Commit SHA | ${{ github.sha }} |" >> $GITHUB_STEP_SUMMARY
echo "| Actor | ${{ github.actor }} |" >> $GITHUB_STEP_SUMMARY
echo "| Workflow Version | ${{ env.WORKFLOW_VERSION }} |" >> $GITHUB_STEP_SUMMARY
echo "" >> $GITHUB_STEP_SUMMARY
echo "### Usage" >> $GITHUB_STEP_SUMMARY
echo "" >> $GITHUB_STEP_SUMMARY
echo "Reference this version in your workflow:" >> $GITHUB_STEP_SUMMARY
echo "" >> $GITHUB_STEP_SUMMARY
echo "\`\`\`yaml" >> $GITHUB_STEP_SUMMARY
echo "uses: chef/common-github-actions/.github/workflows/ci-main-pull-request.yml@v${{ steps.calc_version.outputs.new_version }}" >> $GITHUB_STEP_SUMMARY
echo "\`\`\`" >> $GITHUB_STEP_SUMMARY
.github/workflows/create-release-tag.yml:249
- The condition "if: needs.create-tag.outputs.new_tag != ''" will not trigger when tag creation is skipped (because the tag already exists). In that case, the "new_tag" output from the create-tag job will be empty, and no GitHub Release will be created. This means if you manually trigger the workflow with workflow_dispatch for an existing tag, no release will be created. Consider whether this is the intended behavior, or if you want to handle the case where a tag exists but a release doesn't.
create-release:
name: 'Create GitHub Release'
runs-on: ubuntu-latest
needs: create-tag
if: needs.create-tag.outputs.new_tag != ''
HOW-TO-USE.md:370
- The date "2025" appears to be incomplete or placeholder. It should include a specific month and day, or at minimum a month (e.g., "Jan 2025" or "2025-01-15") to provide meaningful version history information.
| v1.0.7 | 2025 | Added Polaris configuration options, Go build/test, Habitat Grype scanning |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
updated documentation
removed some options for stub versions
Description
Related Issue
Types of changes
Checklist:
Gemfile.lockhas changed, I have used--conservativeto do it and included the full output in the Description above.